A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.
In the present specification and claims, the following terminology is employed:
An entity is considered to have xe2x80x9ca credit of X dollars for cash receivablesxe2x80x9d, also termed herein AMT, or xe2x80x9cX$ of CCRsxe2x80x9d, if he has been granted the right to accept X dollars in cash.
The term xe2x80x9ccashxe2x80x9d or xe2x80x9c$CASHxe2x80x9d refers to physical money as opposed to other vehicles by which payment can be made such as electronic money, credit cards, cheques, bank transfers and the like.
A client of a system which provides services in return for payment is an entity which pays the system and, in return, receives a service. For example, the passengers of a transportation system are the transportation system""s clients.
The term xe2x80x9cpursexe2x80x9d is used to denote a payment manipulating element. A xe2x80x9cclient""s pursexe2x80x9d is a purse belonging to a client which holds a certain amount of value, either cash or virtual value, which the client may use to pay the system. A xe2x80x9csystem element""s pursexe2x80x9d is a purse belonging to an element of the system, such as one of elements 20, 60, 70, 80, etc., which holds a credit for cash receivables, i.e. an entitlement to receive physical cash.
The following abbreviations and notations are employed in the present specification. The definitions provided herein refer only to a preferred embodiment of the present invention and are not intended to be limiting.
$CASHxe2x80x94Bills and coins (physical cash), normally used as legal tender.
Acquirerxe2x80x94Bank or other Issuer who clears transactions.
a Alphaxe2x80x94the first letter of the Greek alphabet.
A (a)
AAC Application Authentication Cryptogramxe2x80x94A response sent by the SAM/SC indicating a rejection of a transaction.
AAR Application Authorization Referralxe2x80x94A response sent by the SAM/SC indicating a request for a referral.
AC Application Cryptogramxe2x80x94A cryptogram sent by the SAM/SC indicating the state of a transaction.
ACC Application Currency Codexe2x80x94Identifies what currency is used in a transaction
ACN Account Numberxe2x80x94A unique number identifying smart card""s account with an issuer. See PAN.
ACK Acknowledgmentxe2x80x94Confirmation of acceptance of transmission. Application Default Actionxe2x80x94A data element indicating the action a card should take for certain exceptional conditions.
ADF Application Definition Filexe2x80x94A file that contains data which defines application properties.
AED Application Expiration Datexe2x80x94A closure date after which application may cease to be valid.
AEF Application Elementary Filexe2x80x94A basic file that contains data which can be used by the SAM/SC.
Application Elementary File Data Templatexe2x80x94Attributes of a file stored in the FCI.
Application Effective Datexe2x80x94Starting Date from which the application may be used.
AFL Application File Locatorxe2x80x94A string divided into fields of typically four bytes, pointing to file and record numbers, containing relevant application information.
AID Application Identifierxe2x80x94Identifies the application as described in ISO 7816-5, comprises the RID and the PIX.
ISO7816xe2x80x94The set of standards for manufacturing ICCs. Serves as basis for most other
Parts 1+5 standards.
AIP Application Interchange Profilexe2x80x94Indicates capabilities of the card.
AMD Application Management Dataxe2x80x94
AMT Amount of Transactionxe2x80x94A Binary Coded Decimal, exact to 1/100, in the present example.
[AMTXY] Subscript DP signifies the amount to be collected by a parking meter for parking until the end of the regulated parking day, e.g., parking may be free from 7:00 PM.
Else, subscript XY signifies AMT transferred from X to Y.
an Alphanumericxe2x80x94A data sequence which may represent letters, punctuation marks, and numbers (characters). ASCII is for alphanumerics.
ans Alphanumeric Specialxe2x80x94
APC Automatic Passenger Counting systemxe2x80x94an electronic system which audits the number of passengers in an autobus.
APDU Application Protocol Data Unitxe2x80x94A command response, data template or data structure
AR Account Receivablesxe2x80x94an archive of completed transactions, preferably with PK proof, typically with identification and time of transaction. The account receivable archive is external to the SAM; as opposed to the CAR, the credit for accounts receivable, which may only be a PK protected re Archive File (Cryptographically Linked)xe2x80x94A working file which is composed of data fields which are linked together in a fashion such that removal of or alteration of data in any Archive File field can be detected.
Asymmetric (PKC)xe2x80x94Public Key Cryposystems where all subscribers have unique (not shared) secret keys and unique, universally available public identifiers.
ARPC Authorization Response Cryptogramxe2x80x94A response, sent by the issuer, upon receipt of an ARQC, which proves its authenticity.
ARQC Authorization Request Cryptogramxe2x80x94A response, sent by the card, indicating a request to go on-line.
ATC Application Transaction Counterxe2x80x94The transaction numerator which is incremented at every transaction performed by a SAM/SC.
ATM Automated Teller Machinexe2x80x94A remote banking machine for distributing money and performing other functions generally performed by a human bank teller. (Banking)
ATM Automatic Ticketing Machinexe2x80x94see TIM
ATR Answer to Resetxe2x80x94A data string emitted by a smart card ICC at reset, to supply information, e.g., the type of circuit, operating system ID, communication parameters, etc.
Auth. Authenticationxe2x80x94proving the validity and acceptance of liability to a string of data (certificate), usually to prove identity of a device, either as a preamble to a transaction or as a control to access.
b Binaryxe2x80x94An Integer number system where all numbers are represented by strings of modulo 2 digits (bits), e.g., each digit is either a one or a zero. The string 1011 is equal to 23+21+20=11.
BAL Balance in a purse
BCD Binary Coded Decimalsxe2x80x94A binary code where each decimal digit is represented by a nibble (4 bits). bitxe2x80x94a binary digit, i.e. a bit can be equal to a one or a zero.
BER-TLV Basic Encoding Rules Tag Length Value
BGT Block Guard Timexe2x80x94see T=1 timing.
BIN Base Identification Numberxe2x80x94Blind transfer. Sending an electronic transaction over an open channel, without first establishing a formal link with a second party, e.g., depositing an electronic cheque in a mailbox, without explicitly communicating with the recipient, while enabling the recipient of the transfer to credit his internal purse without performing a clearance via a trusted third party, e.g., a bank, Visa, etc.
See CCCR and RCCCR.
bus (Motorola often prints buss)xe2x80x94an internal data channel which connects a
CPU with its peripherals.
BUI Bus (Autobus) Interface Unitxe2x80x94Connects the TIM""s bus peripherals, power supply, network interface, etc. to the TIM""s motherboard.
BWI Block Waiting time Integerxe2x80x94see T=1 timing.
BWT Block Waiting Timexe2x80x94see T=1 timing.
C-APDU Command APDUxe2x80x94for T=0 timingxe2x80x94Command+Data sent from an application to the TTL.
CAR Credit for Accounts Receivablesxe2x80x94The mechanism, (very similar to the CCR), meant to control account value (generally electronic) received and transferred by SAM/SCs. Generally, such value will be handled by a central clearance organization (see acquirer). When electronic value is accepted by a SAM/SC, e.g., a vending machine, a TIM, a parking meter, following rules established by the SC issuer, the SAM/SC""s CAR is decremented. Means and methodology in this document with relation to transfers of CCRs may be applicable with CARs. However, the motivation for full authentication of the terminal to the SAM/SC is diminished by the inherent delay in debiting and crediting ECASH, and the decreased value of ECASH to a rogue or a rogue organization, owing to the traceability of an ECASH transaction, and the efficient clearance abilities of the acquirer.
For example a cash advance public key smart card parking transaction is demonstrated;
assuming that all financial service and handling charges between a parking meter (PM) operator, an ECASH purse operator and credit card applications are reconciled on a monthly basis, and that these service charges are not relevant to the transactions involved; and assuming that the client who is paying for parking services (the cardholder) has two applications, a public key credit smart card, and a public key ECASH smart card, either on the same smart card or on two separate public key SAM/SCs, preferably both able to authenticate to the PM that they have the same owner;
and assuming here, entitlement to load ECASH into a client""s purse (tantamount to printing electronic money) is granted to a secured PM, where the source of the payment is a client""s credit card giving a xe2x80x9ccash advancexe2x80x9d, and assuming that the PM operator""s strategy for risk assessment, in addition or in place of the EMV strategy for off-line assessment of risk collections, is to allow a cash advance only for the exact amount necessary to pay for parking for a full day (AMTDP), (about $40), and for only one cash advance per day without going on-line and that it immediately charges for the first double time increment, and will only return the surplus when the client returns to take his vehicle, and no sooner than 15 minutes from the client""s initializing of the transaction;
as the meter receives AMTDP from the client""s SC credit card, the meter""s credit receivables purse is incremented; the PM""s CCR entitlement is decremented; as the TPMP is incremented by AMTDP; and the TPMP purse is immediately decremented by the PM_INC""s first two increments of ECASH reducing the CAR by the same amount and incrementing the accounts receivables (AR) purse by the same sum;
subsequent time increments elapsing before the return of the client with his SC will activate additional incremental transfers from the TPMP to the AR purse, and decrements from the entitling CAR;
when the client returns to retrieve his vehicle, he inserts his smart card; the TPMP is entitled to return to the cardholder the remainder of the ECASH left in the TPMP from the credit card cash advance to replenish the cardholder""s ECASH purse; the total parking transaction is archived in the accounts receivable purse.
Assume that there was only this single parking transaction, and that the meter accepted $16 for parking, and received a cash advance of $40 from the credit card application. The PM would have returned $24 to the cardholder""s ECASH purse; used $40 of the PM""s entitlement; taken $40 of credit receivables to be given eventually to the ECASH purse operator who would use it to dun the credit card acquirer, and $16 of accounts receivable to be used by the PM operator to dun the purse operator for parking services.
When servicing the PM, the warden""s terminal would unload the PM""s CRs into its own CR purse, decrement the warden""s CCRs by $40 to replenish the PM""s CCR back to the PM""s maximum CCR entitlement; and then unload the $16 of ECASH from the PM""s AR purse, into its own AR purse, decrementing the warden""s CAR and incrementing the PM""s CAR by $16, to return the CAR to its maximum entitlement.
When the Warden or RF network connection xe2x80x9cdunsxe2x80x9d the meter, the warden""s xe2x80x9cdunningxe2x80x9d terminal archives and transmits proof of ARs collected (parking tariff) to the operator""s accounting system and ECASH reloaded in client purses.
Cashbackxe2x80x94the ability to cancel a transaction and return value. In the normal merchant client transaction an option can be allowed to cancel the last transaction in a client""s card, if and only if the request is for cancelling the very last transaction.
Cashback Pursexe2x80x94In the driver traveller scheme, a preferred feature is cancelling of a hardcopy ticket purchased with $CASH. The specification preferably allows the driver the option of returning full or part fare in $CASH to a traveller if a claim is made in reasonable time, e.g. a traveller who took a bus in the wrong direction and realized his mistake in the first one-half hour of the trip.
E.g., for this purpose, the OPM also has a Cashback Purse which is incremented with Cashback Credit each instance that the driver prints a cashback receipt on the TIM. When the driver reconciles $CASH and CCRs with an entitled acceptor of cashback credit, e.g. a depot treasurer, he deposits cashback credits and $CASH with the depot treasurer and receives CCRs equal to the sum of cashback and $CASH. Such an entitled cashback credit acceptor is enabled to decrement his CCR purse with the cashback credits received from the driver.
The cashback purse preferably contains a cumulative register which sums all cashbacks from a start date, as a measure of merit for a driver. (A large sum in the cashback summation may signify suspected fraud.)
Cashiers, Depotxe2x80x94Acceptors of moneys from drivers. Depot Cashiers deposit their collected funds with the Depot Treasurer At present, Depot Cashiers are sellers of tickets to drivers. In some depots, the treasurer may also act as a depot cashier.
Cashiers, Ticketxe2x80x94Sellers of tickets to passengers at depots. Also have TIMs and OPMs.
CBC Cipher Block Chainingxe2x80x94A typical feedback mode of DES En/Decryption wherein many blocks of data are sent, often quite similar messages are dispersed to varied recipients. Here the results of one encryption are XORed to the following block. Any change in the first block will assure non-identical encryption of following blocks, should the following data be identical.
CCCR Cheque for Credit for Cash Receivablesxe2x80x94A cheque sent over an open channel to replenish CCRs without handshake, as opposed to a purse to purse CCR transaction, wherein two SAM/SCs communicate in a handshaking protocol. The CCCR can only be deposited once, and only by the recipient whose PAN and ATC numbers appeared in the RCCCR. See CCR and RCCCR.
CCR Credit for $CASH Receivablesxe2x80x94the credit limiting license granted to a system employee or device to collect $CASH or $CASH equivalent (e.g. a xe2x80x9ccash advance from a credit cardxe2x80x9d), from consumers. This credit is held in a purse in a SAM/SC, protected by strong PKC.
In the system steady state, in a one to one transaction, these credits can only be incremented in one purse if decremented by the same amount from another system purse.
When a vendor accepts AMT of $CASH for the system from a consumer the vendor""s CCR is decremented by AMT and he typically executes a system xe2x80x9cpurchasexe2x80x9d in order to decrement his CCR. An example of such a purchase; in a purse to purse transaction with a consumer""s purse in a CSC, a lottery ticket seller, who is entitled to load ECASH in CSCs, accepts AMT of $CASH, wherein he increments AMT of ECASH in the client""s CSC, he purchased ECASH from the system (e.g. the client""s ECASH purse), while decrementing his CCR by AMT. His CCR may subsequently be replenished by a CCCR sent to him by electronic mail, after he has deposited $CASH at his local bank.
In transactions between system employees, where $CASH is handed from one to another, reconciliation is executed purse to purse, wherein the recipient of the $CASH""s purse is decremented, and the depositing employee""s purse is incremented.
To demonstrate another such $CASH transaction; a driver deposits AMT of $CASH receipts with a cashier. The cashier accepts the $CASH; during the transaction the cashier""s CCR purse is decremented by AMT, and the driver""s purse is replenished by AMT.
CCR can also be incremented with receipt of a CCCR. When the (payer) sender of a CCCR writes the cheque, his CCR is reduced by the equivalent amount. CCRs are only legal tender between system employees or agents, and can only be transferred between SSCs.
A vital link in the CCR mechanism is the use of a REC (an electronic $CASH receipt from a bank or similar repository), wherein the bank signs a receipt for the $CASH deposited. Typically, this receipt can be converted to CCRs only by an entitled entity, e.g., an accountant who can reconcile such RECs with accounts received from the banks and hardcopy receipts sent via internal mail.
CCPS Chip Card Payment Service
CD Committee Draft
CDOL Card Risk Management Data Object Listxe2x80x94A list of data objects used by the card to perform a transaction.
Cert. Certifiedxe2x80x94Authorized by an agreed upon Trusted Authority (whose ID is recorded in non-volatile memory in a SAM/SC).
Certificatexe2x80x94A cryptogram signed by an issuer or a sub-issuer of a system whose public key is known and recognized by the authenticator, thereby proving responsibility and origin of the hashed contents of the cryptogram (generally the hashed data relating to the validity of membership of a cardholder in a community, e.g. a Visa cardholder, his ID, his public key, the period of validity, his credit rating, etc.)
Chequexe2x80x94Here used as an vehicle for a blind secured transaction sent over an open channel, without third party regulated clearance procedure. Cheques (CCCRs) transfer CCRs to recipients who have designated a request, see RCCCRs. See also RECeipts and requests for receipts (RRs).
CID Cryptogram Information Dataxe2x80x94Indicating the type of cryptogram (AAC, ARQC, AAR or TC) returned by the card.
CLA Class Byte of the Command Messagexe2x80x94First byte of a command conveying attributes of command processing
CLK The signal used to drive and synchronize the workings of the CPU (or the state machine in a secured memory chip) in an ICC.
Clonexe2x80x94A device which behaves like another device, under all relevant conditions.
cn Compressed Numericxe2x80x94Same as BCD.
Cons. Consecutivexe2x80x94following immediately, e.g., 369 follows 368 consecutively.
CPLC Card Production Life Cyclexe2x80x94The period of relevance of a card""s life, from embedding of module or Issuance to end of card validity.
CR Credit Receivables-An archive of credits which are to be presented to a credit organization, in the parking meter scenario, assumed to be in lieu of cash (a cash advance).
In the parking meter scenario, credit receivables contain credits which the meter collected for a purse operator, wherein the parking meter serves as a surrogate for the purse operator, entitling the meter to reload ECASH into clients"" PK smart card purses.
CRL Certificate Revocation Listxe2x80x94listings of disqualified members of a system (black listed users or issuers)xe2x80x94issuers"" and users"" CRLs should be kept in separate files. These listings may be made current at regular intervals.
CRT Chinese Remainder Theoremxe2x80x94an acceleration method for modular multiplication over composite moduli (moduli which are a multiple of two or more factors)xe2x80x94used especially with RSA and sometimes with D-H.
CSC Consumer""s Smart Cardxe2x80x94In a system wherein physical cash ($CASH) and/or ECASH flow is protected using CCRs and/or CARs; a CSC is a smart card held by a consumer whose card can be loaded with electronic cash from an SSC (system smart card). A CSC cannot increment CCRs in an SSC. When a consumer gives an SSC holder, AMT of $CASH to an SSC holder for reloading cash to his CSC electronic cash purse, the SSC""s CCR purse is decremented by AMT, as the CSC""s electronic purse is incremented by AMT. When a consumer gives an SSC holder $CASH to purchase a printed travel ticket, the SSC""s CCR is decremented, while the SSC executes a purchase from the TIM, e.g., the driver receives $10 from a passenger; keys in the xe2x80x9cpurchasexe2x80x9d on the terminal, thereby decrementing his CCR by $10, to make a purchase from the terminal, which prints the $10 travel voucher; the terminal archives the purchase in a file for further reconciliation by accounting but does not increment a CCR.
When a consumer gives an SSC holder $CASH to purchase a multiple smart card travel ticket, the SSC""s CCR is decremented, while the SSC executes the purchase from the TIM, whence the TIM opens a secured file in the CSC e.g., the driver receives $20 from a passenger; keys in the xe2x80x9cpurchasexe2x80x9d of a day pass (or a multiple local 6 ticket or a special fare excursion . . . ) on the terminal, thereby decrementing his CCR by $20, to make a purchase from the terminal, which prints the $20 travel voucher; the terminal archives the purchase in a file for further reconciliation by accounting.
CSN Card""s Sequence Numberxe2x80x94A counter, managed by the card, which is increased with each transaction and authentication. See ATC.
Cum. Cumulativexe2x80x94a process where all values are added together.
CVM Cardholder Verification Methodxe2x80x94A data object read from the card, indicating the procedure used to verify the card holder (PIN).
CVR Card Verification Resultsxe2x80x94A data object, managed by the terminal, indicating the result of the authentication check of card holder.
CVV Card Verification Valuexe2x80x94
CWI Character Waiting Time Integerxe2x80x94See T=1 timing.
DAD Destination node Addressxe2x80x94T=1 transport layer.
DDF Directory Definition Filexe2x80x94A file that contains entries for other DDFs and ADFs in the current directory.
DDOL Dynamic data authentication Data Object Listxe2x80x94Data Object list that is used to perform authentication.
DEA Data Encryption methodxe2x80x94symmetric cryptographic method used in DES)xe2x80x94
DEK Data Encryption Key (shared secret between 2 DES subscribers) Depositxe2x80x94The amount (or act of giving) receivables, e.g. to a treasurer or teller. Depotxe2x80x94In the mass transportation deployment any station or substation on line to central computer where transactions between drivers and cashiers/treasurers are executed.
DES Data Encryption Standardxe2x80x94de jure symmetric crypto standard.
DF Dedicated Filexe2x80x94A file containing directory entries, or application definition data.
D-H Diffie-Hellmanxe2x80x94public key method for secret key exchange.
DIR Directory Filexe2x80x94A DDF that includes only EMV applications.
DIS Draft International Standard
DK Derivation Keyxe2x80x94One of the 16 different 48 bit Secret Keys derived from a 56 bit DES Master Key. For triple DES there may be two Master Keys.
DN Data Block N
DSA(DSS) Digital Signature Method (Standard) NIST method for documentation integrity Dual Message Transactionxe2x80x942 stepxe2x80x94Authenticationxe2x80x94then clearance Dynamic Data Authenticationxe2x80x94Proving authenticity by answering a challenge using a secret without divulging the secret.
DTA
EasyEntry Visa specxe2x80x94file for all MagStripe Info in every Visa ICC application, to provide a minimum of compliance to old applications.
ECASH Electronic value, commensurate to a national currency, kept in a consumer""s ICC purse, and in some payment schemes, in a vending device.
ECB Electronic Code Bookxe2x80x94A mode of use for DES, wherein a block (64 bits) of plain text is encrypted to 64 bits of ciphertext. Note that for the same key and the same block of plain text, the result will always be identical. See CBC.
EDC Error Detection Codexe2x80x94A system of adding redundant code to blocks of message, wherein it is possible to determine (but not necessarily detect) that an error of up to a predetermined size has occurred within the block.
EDT Electronic Data Transactorxe2x80x94Transaction terminals for depots, communicating with central data processing computer. All raw data is transmitted for processing in a central computer.
EEPROM Electronically Erasable Programmable Read Only Memoryxe2x80x94Non volatile memory which can be written to/erased in small increments.
EF Elementary File (ISO, EMV, PC3)
EMV Work group consisting of Europay, MasterCard and Visa formed to standardize smart card payment systems, based on ISO 7816 specs, RSA, SHA1, triple DES, etc.
Entitlement to accept $CASH, ECASH. The CCRs and the CARs are the vehicles which put working limits on the entitlement of devices, agents, or employees in a payment system to accept physical cash or electronic value. Entitlementxe2x80x94The procedure allowing an issuer or a subissuer the proper priority to access applicationsxe2x80x94no access, read only, write only and read and write. In a payment scheme, additional entitlements may be appended; e.g., enabling the acceptance of receipts, cheques, etc.
ETICKET Electronic ticket(s) or voucher(s), equivalent to hardcopy ticket(s) and voucher(s). Typically, these tickets reside in secured purses within a PKC Smart Card, adjunct to a control file which regulates usage.
etu Elementary Time Unitxe2x80x94Used to define the synchronized baud rate between ICC and terminal.
FCI File Control Informationxe2x80x94A template, returned by the card, containing relevant data options about the accessed file.
FCP File Control Parametersxe2x80x94A template used by the EMV to control file parameters, can be part of the FCI.
Firewallxe2x80x94a virtual barricade to prevent illicit access to computer systems, typically based on sound authentication methodology.
FIPS Federal Information Standardxe2x80x94NIST designation for US Government approved standards.
FMD File Management Dataxe2x80x94A template used by the EMV to control file parameters, can be part of the FCI.
Floor Limitxe2x80x94an EMV value variable, above which a terminal has the option to transfer the negotiation process to the On-Line host Free Access Pursexe2x80x94A client purse for executing accelerated preferably small payments. A purse that allows a terminal free access is designed for those payments where the SC holder recognizes the terminal (a transportation ticketing device, a parking meter), where he has reasonable confidence that the terminal is operated by a responsible party, and where he can assume that he can immediately ascertain what transactions the terminal has executed, and that he will have sufficient proof in his history file, to rectify any aberrations, e.g., when a traveller inserts his SC in a TIM, the CAR purse to purse protocol will not include the TIMs proving to the SC that the TIM belongs to the bus company and is entitled to collect ECASH; however the SC does prove to the TIM that it has decremented its purse by the AMT demanded by the TIM, after having archived the transaction in the SC""s history file.
Frozen Protocolxe2x80x94procedures which are followed assuming the inviolability of SAM/SC modules and terminal procedures.
GPO GET PROCESSING OPTIONSxe2x80x94An EMV command that initiates a transaction by sending processing options to the smart card. In return, if the smart card approves the processing options, it sends the AIP and the AFL. Hackerxe2x80x94a real time programmer who find weaknesses in systems with intention to penetrate networks and databases.
Hashxe2x80x94a nonsecret one-way transformation of data, usually converting a large string to a much smaller stringxe2x80x94usually prior to signing the smaller stringxe2x80x94to prove authenticity of a large stringxe2x80x94see Message and Signature. See SHA1.
hex. Hexadecimalxe2x80x94also xe2x80x98nnnxe2x80x99 as in xe2x80x989F01xe2x80x99 or $9F01 as in Motorola.
HHMM Hours, Minutesxe2x80x94A 4 byte real time data segment.
HHMMSS Hours, Minutes, Secondsxe2x80x94A 6 byte real time data segment. History Filexe2x80x94A rotating file of last purse transactions performed by a SAM. In general, only the cardholder and the issuer (not the issuer""s agents) have entitlement to read the file on any system terminal. This permits the cardholder to confirm the actual value of his transactions. The card issuer determines how many xe2x80x9clast transactionsxe2x80x9d can be stored in the EEPROM.
IAC Issuer Action Codexe2x80x94A set of issuer defined action lists, indicating the behavior of the card, in different situations.
I-Block Information Blockxe2x80x94in the T=1 transportation layer, the command+data set which is transmitted from the TTL to a SAM/SC.
IC Integrated Circuitxe2x80x94A microelectronic device on which there are a multiplicity of transistors, resistors, capacitors, etc. usually to manipulate digital data.
ICC Integrated Circuit Cardxe2x80x94a smart card with an embedded secure CPU module, preferably with PKC protection.
IEC International Electrotechnical Commissionxe2x80x94one of several standardization agencies defining ICC device specs, working with ISO.
IFD Interface Devicexe2x80x94Generally an ICC reader.
IFS Information Field Sizexe2x80x94See T=1
IFSC Information Field Size for the ICCxe2x80x94See T=1.
IFSD Information Field Size for the Terminalxe2x80x94See T=1.
IFSI Information Field Size Integer
INF Information Field
INS Instruction Byte of the Command Messagexe2x80x94According to ISO 7816 structure, typically.
ISO International Organization for Standardization issuers of internationally accepted technical standardsxe2x80x94see Normative References.
ISOXX(xc2x7) ISO Format Function 9796 onXX bytes of text (specified in parenthesis)xe2x80x94a data structure for electronic signatures to protect message/document integrity.
Issuerxe2x80x94Card Issuer or Card Issuer""s Agent
Journal Printerxe2x80x94An internal device which prints a record of every transaction, e.g., on a continuous tape.
KM Master Keyxe2x80x94A shared secret key in a DES system.
KS Session Keyxe2x80x94A (DES) Key, which is generated for, and used only once, securely exchanged for use in accelerated transmission of data between two implicitly trusting communicants.
LC Length of the Command Data Fieldxe2x80x94Number of bytes in a command.
1 cm least common multiplexe2x80x94the smallest factor that is common to two numbers. The 1 cm of two different prime numbers is one.
LD Length of the Plaintext Data in the Command Data Fieldxe2x80x94a one byte variable defining the length (in bytes) of plaintext data.
LDD Length of the ICC Dynamic Dataxe2x80x94A one byte variable.
Lc Maximum Length of Data Expected by the TAL in Response to a ISO 7816-4 Case 2 or 4 Command
LEN or Lengthxe2x80x94Length of Data in Bytes (a one byte variable).
len
Licc Exact Length of Data (denoted by a one byte variable) available in the ICC to be Returned in Response to the 7816-4 Case 2 or 4 Command Received by the ICC
Lockxe2x80x94A closure put on an application(s) by a terminal, an issuer, or by internal negotiation within the ICC, preventing access to such applications. Some closures can be removed by the issuer, probably after card user has fulfilled obligations, or following return of card to rightful owner.
Lr Length of Response Data Fieldxe2x80x94Length of Data in bytes received by the Terminal.
LRC Longitudinal Redundancy Checkxe2x80x94A check of transmitted data integrity.
M Mandatory
MAC Message Authentication Codexe2x80x94A one way function, using an accepted key, usually in symmetric cryptography (with publicly known DES keys), to prove the validity of a document, and its origin. See also hashes and signatures in public key cryptography.
Messagexe2x80x94a binary string which may include random or formatted data, and/or a Hash of said data.
MIC Message Integrity Check
MIN(I) A variable time increment in a service tariff table, e.g., in a parking meter tariff table in a very busy street, the zero""th time increment might be 15 minutes, (at a lower PM_INC(0) tariff of $0.50), and the 3rd time increment might be 60 minutes and call for a tariff, (PM_INC(3), of $10.
MIPS Million (Assembly Language) Instructions Per Secondxe2x80x94a commonly used measure of computational performance.
n Numericxe2x80x94A data string of xe2x80x9ccountablexe2x80x9d values on which computations can be executed in integer mode only.
N/A Not Applicable
NAD Node Addressxe2x80x94In T=1 transport level, the addresses of the source and destination.
NAK Not Acknowledgedxe2x80x94A signal transmitted by a receiver denoting inability to correctly receive a message.
NCA Length of Certification Authority""s Public Key Modulus in bytes.
NI Length of the Issuer""s Public Key Modulus in bytes.
NIC Length of the ICC""s Public Key Modulus in bytes. Nibblexe2x80x94A group of 4 bits of binary data (one half of a byte).
No. Numberxe2x80x94A mathematical definition of a total of finite items, which can be used directly in computations.
O Optional
One way function. Any function which is relatively easy to perform, but is computationally unfeasible to reverse, e.g., squaring a large integer over a composite modulus is very easy, but finding the square root of such a number is considered computationally intractable to an attacker who does not know the secret factors of the modulus.
Off-Line Terminal/Transactionsxe2x80x94Instances where negotiations and risk management are handled by a remote terminal. Most PKC applications are executed Off-Line. An off-line terminal may have a dial-up option for updating and data transfer. Using public key protocols, risk management can be handled successfully off-line, wherein transactions which do not meet acceptable off-line criteria, will either be refused, or if the on-line terminal option is available, the terminal can go on-line to central clearance.
On-Line Terminal/Transactionsxe2x80x94Transactions, preferably asymmetric, where the remote terminal serves as an intermediary to a central Host which negotiates directly with the external device. In the EMV scenarios, all ATM transactions (value transfer to a user) are On-Line. In PKC applications, fewer transactions must be executed On-Line.
OPM Operator""s Personal Module. An enclosed device which contains protected transaction memory and a SAM/SC to protect transactions and gain access. Acts as a Smart Card with a large external memory.
P1 Parameter 1xe2x80x94In ISO 7816 standard command, the first number which appears after the command.
P2 Parameter 2xe2x80x94In ISO 7816 standard command, the second number which appears after the command.
P3 Parameter 3xe2x80x94In the EMV extension, the third number which appears after the command (used to specify length of data).
Parameter Printerxe2x80x94A printer which accepts commands (e.g., for following $45) for complete lines of data with additional parameters, e.g., xe2x80x9cTime elapsed from start of journeyxe2x80x9430 minutes, kilometers 34.xe2x80x9d xe2x80x9430 and 34 are parameters; e.g., the complete command would be 45, 30, 34.
Personalizationxe2x80x94The procedure followed by an issuer wherein a smart card or SAM/SC is assigned to a subscriber with unique identification, and file structures are programmed into the EEPROM with access priorities and keys.
PAN Primary Account Numberxe2x80x94the EMV identifier of an account.
PCA Certification Authority""s Public Key.
PCB Protocol Control Byte
PDOL Processing Data Object Listxe2x80x94list of data objects that a system uses to initiate a transaction.
Phase Axe2x80x94first deployment of TIM on 200 busses. Basic System experiments.
Phase Bxe2x80x94System expanded with complete transition to Smart Cards.
Phase Cxe2x80x94Total deployment with Smart Cards.
PIN Personal Identification Numberxe2x80x94A unique number, preferably known only to the owner of a SAM/SC or smart card or an application, wherein, assuming the integrity of the keyboard used to authenticate the rightful user of said SAM/SC, and which can be used to activate the SAM/SC.
PIX Proprietary Application Identifier Extensionxe2x80x94In a proprietary approved EMV application, an extension to the AID giving parameters necessary to regulate the application.
PKC Public Key Cryptographyxe2x80x94One of asymmetric message systems using integrity methods with public-private key pairs, e.g., RSA, D-H, DSS, E1 Gamal, Schnorr, Fiat Shamir, etc.
PM Parking Meter. (See OPMxe2x80x94former alias) A device used by public authorities to regulate parking times commensurate to the AMT which a SC grants to the meter.
PM_INC(I) The price of a time increment in a service tariff table, e.g. the tariff for parking in a parking space reserved for load/unload for the zero""th 15 minute increment might be $0.10, whereas in the tenth thirty minute increment might be $40.
POS Point of Servicexe2x80x94A terminal, capable of performing a transaction on a smart card, in exchange for a service.
Proprietary Encryption Methodxe2x80x94Usually a symmetric encryption method wherein the user assumes added security because of the adversary""s ignorance of the method. Generally considered dangerous in an open system.
PSA Payment System Application
PSE Payment System Environmentxe2x80x94A smart card based payment system environment, including POS, terminals, etc.
PT Command to Perform Transaction followed by Terminal Certificate on Data (SCOS++)
PTICKET Printed Ticketxe2x80x94A paper travel voucher purchased with AMT of $CASH issued by a TIM. The driver""s OPM""s CCR is reduced by AMT as it purchases the voucher from the TIM (or the parametric printer""s SAM/SC).
PTR Portable Ticket Readerxe2x80x94Inspector""s tool to confirm proper procedure and one to one agreement between moneys received, tickets issued, credit for cash receivables reduced, and validity of passenger""s proof of payment.
PTS Protocol Type Selection
Pursexe2x80x94In the SCOS++ operating system, a secured purse consists of public key protected files encapsuled within a secured silicon architecture. An SCOS++ purse can only be loaded with value by another purse, wherein the value held in the donor purse is decremented, and the value held in the recipient""s purse is incremented.
A purse with proper entitlement can be loaded by a valid donor purse using one or more of the three mechanisms; as on-line purse to purse transaction; a cheque for credit for value ($CASH or ECASH) receivables possibly sent to a mailbox over an open, interceptable channel; a receipt signed by a system recognized repository (a bank). Entitlement is subject to system strategy, e.g., in a preferred strategy only an accountant can convert RRs to CCRs in his SAM; similarly only Depot Managers and Treasurers and Cashflow Managers are entitled to request and receive CCCRs.
Purse to purse transactionsxe2x80x94Purse to purse transactions are performed generally between two $CASH purses in SAMs, linked through what may be a dumb terminal. In a $CASH purse to purse process, a very rigorous mutual authentication negotiation is executed with public key signed challenges and responses and confirmations, assuring that one purse is not charged and another not made beneficiary unless the negotiation procedure has been executed properly and in its entirety.
PV Private (Secret) Key in PKC used for Signature SPV(xc2x7) and Decryption (RSA)
PVV PIN Verification Valuexe2x80x94A transformation of the PIN value enabling the system operator to verify the validity of the PIN, without broadcasting a client or system secret PIN in the clear over an open channel.
RAM Random Access Memoryxe2x80x94Memory which be specifically addressed, then written to (changed) or read from with relatively fast access time (10 to 150 ns).
R-APDU Response APDUxe2x80x94Response of Data and Status from the Transport to the Application layer.
R-Block Receive Ready Blockxe2x80x94A T=1 signal.
RCCCR Request for a Cheque for Credit for Cash Receivablesxe2x80x94the token generated by a potential receiver of a CCCR""s SAM/SC to enable the SAM/SC to enable the SAM/SC to accept a single cheque from a designated source, assuring the writer of the CCCR that the cheque can and will be used to credit the receiver""s CCR once, and only once.
Remote (Terminal)xe2x80x94A terminal device which does not normally communicate with a central host computer.
RECB A receipt from B, probably the bank who is not a fully participating actor in the system, proved by the signature on an RR and relevant data attesting to AMT of $CASH having been deposited in a receptory (a bank or a clearing organization). Only entitled recipients can convert the AMT in a REC into CCR. The mechanism is similar to xe2x80x9ccashingxe2x80x9d a CCCR.
RF Radio Frequency Communication. An option for allowing dispersed not otherwise communicating devices, to go on-line to a central node for reconciliation, downloading CRLs, for uploading transactions, etc.
RFU Reserved for Future Use
RID Registered Application Provider Identifierxe2x80x945 bytes which uniquely identify an application provider.
R N or Random Number, unpredictable number (sequence of 1 and 0 bits), physically
RND generated and computationally randomized.
RNG Random Number Generator. Preferably a Real Random Number Generator which generates a completely unpredictable number under all conditions.
ROM Read Only Memoryxe2x80x94non-volatile immutable memory, that can be read from, but not written to.
RPA Request Purse Accountxe2x80x94to ICC to supply an AC, which includes present status of account, type of transaction willing to perform, and an RN, generated by the ICC (SCOS++).
RRXY Request for Receipt. X requests an electronic receipt from Y. This assumes that X has the authority to convert a receipt into an increment to X""s CCR or CAR.
This function is typically used by accountants who reconcile receipts with accounting statistics and transfer CCRs to a company treasurer whose duty is to send CCCRs to dispersed $CASH collectors.
This signed request for receipt typically includes proof of X""s belonging to the system, and data issued by X""s SAM/SC which will enable to convert said receipt once, and only once into CCR or CAR (CxR).
RSA Rivest-Shamir-Adelman Methodxe2x80x94most flexible and de facto standard PKCxe2x80x94for electronic en/decryption, key exchange and document signature.
RS485 See Standard Serial Communication.
RST Resetxe2x80x94A software or hardware triggered initialization, which erases sensitive data and forces the system into a safe starting procedure.
RTC Real Time Clockxe2x80x94A vital component in a secured system to attest to the time that a transaction is performed.
R-TPDU Response TPDUxe2x80x94Response received by the terminal transport layer from an ICC.
SAD Source Node Addressxe2x80x94In T=1, that part of the NAD which indicates the source of a block of data.
SAM Secure Access Modulexe2x80x94A Motorola SC49 or CF54, for example, can be embedded in a smart card, or the security module in a larger computing device.
S-Block Supervisory Blockxe2x80x94In T=1, used to send control blocks.
SC, SCx. Smart Card or SAM. Subscript x signifies SC or SAM belonging to x.
SC1, SC2 In a specific scheme, SC1 generally defines the granter of value, SC2 the acceptor of value.
SCA Certification Authority Private Key.
Scriptxe2x80x94in EMV nomenclature, a sequence of commands coupled with data to be conveyed by the terminal to the ICC without interpretation.
Secured ICC architecturexe2x80x94a monolithic silicon cryptocomputer, essentially characterized to disallow illicitly invasion, with a virtually inviolate internal bus, no test points, hardware to disable running at low speeds (less than 0.5 mhz), insuring a block erase of EEPROM when top metal layer is scratched, etc.
SFI Short File Identifierxe2x80x94A unique 5 bit number used to access an EF within the same application or directory.
S1 Issuer""s Private Keyxe2x80x94The Secret (only RSA in present EMV specs) key used by the issuer to sign certificates of participants in the Issuer""s applications.
S1C ICC""s Private Keyxe2x80x94The Secret key (RSA in EMV) embedded in the EEPROM.
In the xe2x80x9coff the shelfxe2x80x9d SCOS+, ICCs, this key is generated by the card, within the card, and is in a secured section of the EEPROM, accessed only by the proprietary library.
Signaturexe2x80x94Computational transformation on a message using a signer""s private key, proving document integrity and liability of signer to unalterable contents. EMV authorize the RSA method for signatures. Usually part of a signature is composed of a hash on large quantities of data, to enable a single signature to prove integrity of more than one block of data. See SHA1, DSA, and RSA.
SHA1 NIST""s Secured Hash Methodxe2x80x94a very strong one way function to transform a long data string into a 160 binary bit sequence for signing with the DSA or other signature methods. (Second rendition, first was designated SHA). Standard Serial Communicationxe2x80x94RS485xe2x80x94A multidrop noise resistant network standard, often used for in situ automotive peripheral communication. Static Data Authenticationxe2x80x94Off-line asymmetric PKC authentication of certificates as opposed to dynamic data authentication, wherein both prove their identities and can prove integrity of messages.
SSC System Smart Cardxe2x80x94In a system wherein $CASH flow is protected using CCRs, a SSC is a card or SAM held by employees of the system which are entitled to accept cash in return for CCRs. When an SSC accepts $CASH or writes a cheque for credit for cash receivables; its CCR is decremented by AMT if it received $CASH; its CCR is incremented by AMT if it bestows $CASH. When an SSC loads a Consumer""s Smart Card with electronic cash, the SSC""s CCR is decremented and the CSC""s electronic purse is incremented with electronic cash. Electronic cash ordinarily, cannot be transformed, off-line, back into CCR. See CSC.
SW1,SW2 Status Wordsxe2x80x94Returned by the card, to indicate command termination status. Stringxe2x80x94A sequence of ones and zeros. Sweetheartingxe2x80x94A state of collusion where a service or goods provider conspires to defraud his employer while charging a lower than proper AMT.
SXX(xc2x7) xx""s PKC signature on the value in parenthesis. If the data in the parenthesis is longer than the modulus of the signer""s (certifier of validity) modulus, then it is assumed that either the data is signed in parts, or, preferably, the data is transmitted separately, then hashed, and the signature is then performed on the hashed value, and/or on the hashed value and a part of the data that is transmitted along with Sxx.
T Transaction Typexe2x80x94designation of credit/debit, secured/free access balance, cashback, or lock application.
T=0 The original ISO byte oriented single user protocol for data transmission between a contact smart card and a terminal.
T=1 The advanced ISO packet oriented multi-user protocol for data transmission between several smart cards and a terminal. Tachometer/graphxe2x80x94a device measures and charts the speed of a vehicle as a function of time.
TAL Terminal Application Layerxe2x80x94an application program running on the terminal using the TTL to communicate with the ICC.
TC Transaction Certificatexe2x80x94a xe2x80x9cSigned Chequexe2x80x9d.
TCK Check Character
TCLKX A time measuring device used to measure the incrementing period of X""s parking. (measured from time X inserts SC in PM).
TDOL Transaction Certification Data Object List Tear Protectionxe2x80x94A backup firmware methodology to prevent or compensate for illicit or unintentional interruption of a transaction procedure.
TIM Ticket Issuing Machinexe2x80x94A cryptocomputer regulated device that controls money collection, ticket issuing and collection, controls access to vehicle, and collects transaction and automotive data relevant to a payment collection operation.
Time Stampxe2x80x94That part of a certificate which testifies to the time of signature on a string of data.
TLV Tag-Length-Valuexe2x80x94Data object structure definition, preferably according to ISO Basic Encoding Rules.
TPDU Transport Protocol Data Unitxe2x80x94The data unit sent by the ICC to the terminal to regulate communication.
TPMP Temporary Purse in Parking Meterxe2x80x94A purse which receives the client""s parking deposit and dispenses increments to the account""s receivable while client""s car is parked; holding the client""s unspent ECASH; If the xe2x80x9cunspentxe2x80x9d surplus is returned to the client""s smart card when the client retrieves his vehicle; the unspent portion or part therof increments (is returned to) the client""s ECASH purse, any other remainder increments the accounts receivable and decrements the entitlement contained in the CAR.
Tracexe2x80x94A service giver/terminal""s ID string (8 bytes).
Trans. Transactionxe2x80x94A negotiated transmission of data.
TSI Transaction Status Informationxe2x80x94A present assessment of negotiated information.
Transaction Velocity Checkxe2x80x94An method that decides to perform the transaction on-line or continue off-line, dependent on several risk assessment variables.
TTL Terminal Transport Layerxe2x80x94manages the command/response pair transmission sequence between an ICC and a Terminal. Receives an APDU from the TAL and sends a TPDU to the IC.
TVR Terminal Verification Resultsxe2x80x94A bit mask, managed by the terminals containing the status of the card verification process.
UDK Unique DEA Keyxe2x80x94A secret random key, unique to a DES process.
Validatorxe2x80x94In the mass transportation scenario, a Smart Card accepting device to collect value from a multi-ride ticket purse, and for allowing cardholders to read last transactions.
var. Variablexe2x80x94A data string whose value can be changed by authorized members of a defined cryptographic community.
Verificationxe2x80x94Generally the check performed by a cryptocomputer, to ascertain the values contained in a signed transaction certificate.
V.I.P. VisaNet Integrated Payment
Wardenxe2x80x94An inspector whose duty is to inspect violations and failures in a service system (parking meters), and in those systems which cannot communicate on-line to a central database, to download data and CRLs, and transfer transaction data for central clearance.
YDDD Year, Day (xe2x80x98Yxe2x80x99=Rightmost digit of the year (0-9). xe2x80x98Dxe2x80x99=Day of the year (1-366))xe2x80x94A two byte hexadecimal representation of date.
YYMMDD Year, Month, Dayxe2x80x94A three byte hexadecimal representation of a date.
The present invention seeks to provide improved apparatus and methods for computerized control of payment collection.
There is thus provided, in accordance with a preferred embodiment of the present invention, a system for safe collection of payment in return for goods, values or services, the system including a multiplicity of electronic system elements wherein each individual one of the elements has a purse storing an amount of credit for value receivable granted to the individual system element, each purse including a purse monitor operative to sign and authenticate a transaction record of each transaction in which the purse uses some of the credit for value receivable which it has been granted, and a purse control unit operative to prevent the purse, off-line, from exceeding the credit for value receivable which it has been granted.
There is also provided, in accordance with a preferred embodiment of the present invention, a system for safe collection of payment by a vehicle operator from riders, the system including a multiplicity of electronic payment receipt generators, each operable by a vehicle operator, wherein each individual one of the payment receipt generators includes an electronic purse storing an amount of electronic cash, each electronic purse including an electronic cash loader operative to use some of the electronic cash to generate a payment receipt to be given by the vehicle operator to a rider, and an electronic purse control unit operative to prevent said electronic cash loader from exceeding said amount of electronic cash, thereby limiting the vehicle operator""s entitlement to collect payments from riders, and an electronic cashier purse operative to increment the electronic purse of each electronic payment receipt generator by the amount of payment collected by the vehicle operator to whom the electronic payment receipt generator is assigned.
Further in accordance with a preferred embodiment of the present invention, each of the purses includes a SAM (security application module).
Still further in accordance with a preferred embodiment of the present invention, each purse control unit is public-key protected.
Further in accordance with a preferred embodiment of the present invention, the multiplicity of payment receipt generators communicate with the electronic cashier purse in an encrypted manner.
Still further in accordance with a preferred embodiment of the present invention, the multiplicity of payment receipt generators communicate with the electronic cashier purse by employing public key cryptographic signatures.
Additionally in accordance with a preferred embodiment of the present invention, the total amount of all vehicle operators"" entitlements to collect payments from riders is limited to a preset amount. Also provided, in accordance with another preferred embodiment of the present invention, is a method for safe collection of payment by a vehicle operator from riders, the method including providing a multiplicity of electronic payment receipt generators, each operable by a vehicle operator, wherein each individual one of the payment receipt generators includes an electronic purse storing an amount of electronic cash, using some of the electronic cash to generate a payment receipt given by the vehicle operator to a rider, preventing the total amount of payment receipts from exceeding said amount of electronic cash, thereby limiting the vehicle operator""s entitlement to collect payments from riders; and incrementing the electronic purse of each electronic payment receipt generator by the amount of payment collected by the vehicle operator to whom the electronic payment receipt generator is assigned.
Further in accordance with a preferred embodiment of the present invention, the multiplicity of payment receipt generators communicate in an encrypted manner.
Still further in accordance with a preferred embodiment of the present invention, the multiplicity of payment receipt generators communicate by employing public key cryptographic signatures.
Further in accordance with a preferred embodiment of the present invention, the total amount of all vehicle operators"" entitlements to collect payments from riders is limited to a preset amount.
A preferred embodiment of the present invention is now described:
In large and small scale distributed payment schemes, off-line agents (bus drivers, fuel station attendants, merchants, parking meters, vending machines, etc.) are called upon to accept cash or equivalent cash advances from credit granting entities and transfer value to (reload) smart cards. An off-line terminal is one that handles all or some transactions without communicating with a central data-base. These applications, before the introduction of Fortress or similar monolithic silicon cryptocomputers, would not have been practical being subject to large scale interference from fraudulent adversaries.
Operators, who in the past were able to work in a cash-only environment, or others, who may not remember the universality of xe2x80x9cfolding or physical moneyxe2x80x9d as it once existed, would benefit from an electronic purse cash scheme that would be convenient both for consumers and suppliers, with such savings as they once existed. Now, with the advent of electronic money, it is desirable to enhance the option of converting customers"" physical money into electronic cash, simplifying and securing clearance through credit card companies, allowing consumers to be benefited with cash discounts, while spreading an equitable part of the savings to participating vendors and providers of service.
In a typical system, customers benefit from having cash held safely in a protected purse. Participating purse loaders may receive a bonus for handling cash (bills and coins=$CASH) or in any other way reloading electronic purses with electronic cash (ECASH or stored value of any form). The operator benefits from interest on the outstanding float held in the consumers"" smart cards.
An important issue is how the system operator can be assured, that, in such a dispersed system, where the purse loader and the various cashiers may have only the loosest common interest with the purse operator, that all cash and value will be deposited by the purse operator""s agents to the operator""s account. Without proper protection agents who load value into cards may be tempted to engage in xe2x80x98printing moneyxe2x80x99).
This issue is now resolved as there are compact mass produced, securely protected monolithic data protection mechanisms (public key cryptographic) which immutably compel participants (i.e. silicon microchips) to follow system rules (i.e. protocol frozen in the microchips).
The electronic purse, for relatively large transactions, used in true off line applications, is a relatively new technology, due to the only recent advent of Public Key Smart Cards. With these new smart cards, a valid user can prove to any accepting terminal in the system, that the smart card is owned by a valid user, and that at a given time, the card has a credit balance sufficient to cover a proposed transaction.
In a smart card chip such as those manufactured by the applicant/assignee, Fortress U and T Ltd., there may be several purses. The same chip can be uniquely initialized and personalized by several independent issuers, and each issuer may embed a unique variety of purses and information protecting applications in an individual user""s card.
To protect honest users, vendors and issuers from fraud, rules are made and followed to assure the validity of a transaction, and protect honest vendors and consumers.
With credit purchases, general rules of what the EMV calls risk assessment typically include data to prove that an off-line transaction is protected by the cryptographically authenticated knowledge that the purse in the smart card and the accepting terminal are in a valid status; meaning that they are both in good standing, and that the smart card has not used more credit than is allowed, has paid his bills as recently as was demanded, and of course a check for any other aberrations that an issuer might desire, such as a limit on the number of withdrawals in a period of time; the number of purchases that can be made without the vendor""s terminal xe2x80x9cgoing on-linexe2x80x9d to the central computer in order to restore the line of credit in the card. In the Fortress purse each off-line purchase instantaneously reduces the amount of credit available to the user, which can be reinstated in an on-line transaction or in a purse to purse session with an approved agent.
A vendor or service terminal can receive payment for goods and services from either a debit (stored cash value) purse or a credit purse. This electronic money is transferred, probably at the end of the day, to a clearance organization which properly credits his account. The EMV is drafting new rules which will allow the terminal to insist, for instance, that certain payments, usually small payments less than a predetermined threshold, be made only from a stored cash value purse, and larger transactions are made using a regulated debit or credit purse.
It is anticipated that the terminal will either maintain separate purses for each clearance organization, as in all probability, the strategies for each might differ, or it may collect all electronic payments, archive them, hash and sign the hash to testify to origin, and send to a single clearance organization. Purses in smart cards with safely stored electronic cash or electronic credit will make electronically signed purchases, which will benefit from clearance procedures similar to today""s checks and credit card purchases, with a larger degree of confidence than was previously enjoyed.
There are rules for a client depositing $CASH with an agent who then reloads an equivalent value of ECASH in the client""s smart card (replenishing spent value) at an off-line site. This has inherent potential danger as an xe2x80x98unrulyxe2x80x99 terminal reloading electronic cash literally can print money. In this venue, the consumer has assuredly proved his credit by furnishing the purse reloader with cash. The system operator now must be sure that the value reloaded into the consumer""s card is commensurate with the monies the operator is to receive in his bank account from the purse reloader, so that he can compensate vendors for goods and services to be received from card-holders who pay with electronic cash.
Purse to Purse Transactions: In purse to purse transactions, value is removed from one purse and loaded into a second purse. In all such transactions, the value should be commensurate and cryptographically protected. Owners of both purses have controlled access to a xe2x80x98rotatingxe2x80x99 file of last transactions (a history file), enabling them to validate, in any compliant terminal, who, and what monies have been removed or added into their purses. This can protect them from rogue vendors who may have purposefully overcharged or fraudulent terminals which may have xe2x80x98short changedxe2x80x99 the card when loading ECASH.
Direct Purse to Purse transactions: Most purse transfers of small value, the largest number of transactions in this scheme, are consummated between dispersed off-line SSCs (terminals and field operators"" security application modules/smart cards) and consumer/client CSCs. Preferably, the parties identify each other on the spot and terminate a one or two sided authenticated transaction in a maximum of about half second to two second period of customer transaction time.
As the hierarchy in a deployment scheme such as FIG. 1 is ascended, each level of transactions involves larger value physical cash purse to purse transactions, e.g., drivers to cashiers or treasurers, or cashiers to treasurers, in-system employees to validating participants where at each stage the sums of CCRs grow. Collusion between high and low hierarchy participants is most likely. Keeping control of cash with proper archiving, transmission of all raw data to the central computer for filtering, and purse to purse transactions using PKC offer good protection.
The concept of xe2x80x9ccredit for cash receivablexe2x80x9d (CCRs)xe2x80x94CCR is a regulating entitlement mechanism that the system operator may employ to administer the limits of the amount of cash in the float, and to assure that operators of pursexe2x80x94reloading terminals, or any intermediaries who receive cash destined to the system operator are limited in the amount of cash they receive before depositing such physical cash with the entitled SSC holder or bank, and to compel them to remit all of the receipts provide for in an orderly and secured continuation of the cash collection system. When a system smart card""s CCR is exhausted, the owner cannot use his purse to dun a consumer or another system card for cash.
In a system smart cardxe2x80x94consumer smart card, purse to purse (physical cash via SSC to consumer""s electronic cash) transaction, the SSC CCR purse is decremented by the same amount that the consumer""s electronic purse is incremented, e.g. a bus driver who accepts AMT cash from a passenger, to be deposited in the passenger""s cash purse; the driver""s CCR will now contain AMT less, and the passenger will have AMT more in his ECASH purse to be spent on travel or in the bus station, or cashiers to treasurers, in-system participants to validating participants where at each stage the sums of CCRs grow.
In a cash transaction between two system smart cards, the CCR in A is decremented as he receives cash from B, whilst the same value from A""s CCR increments B""s CCR; e.g., a driver brings his $600 in cash receipts to a station""s treasurer; the treasurer""s CCR is decreased by $600, and the driver""s CCR is reloaded with $600, probably following a company rule that at every deposit that the driver makes with a treasurer, the driver must replenish his CCR to the maximum float that the system operator granted him.
The Maximum Total Float and each individual SSC Float. In this system the decision for, and allocation of the CCRs in the float is directed by the committee or board of directors, and the implementation of allocating the amount installed in a system by these directors is authorized by the manager of the cashflow, monitored and reconciled in all phases by the Central Accountant. Subsequent day to day operation can be automatic.
The single entry point for CCRs is via the managing directors to the central accountant. The accountant arranges the individual allotments according to the director""s strategy, and submits, with a single CCR of the total sum to be allotted, accompanied by a list of unsigned CCCRs (cheques for credit for cash receivables) to the manager of cashflowxe2x80x94who electronically allots CCRs, e.g. by simply approving a spread sheet sent to him by the accountant, with a program which commands his smart card to sign the cheques and then to dispatch these cheques for credit for cash receivables; much as he would sign and send present day cheques.
In a transportation system, the only occasions when the directors add CCRs to the float are typically either a system expansion or during a period of inflation.
During system and card initialization, a secured file is generated, which can be read by any terminal, but can only be addressed by the manager of cashflow. This file contains the limit of CCRs which can be loaded into a card, and an optional date of expiration. In general, this file can only be changed by the manager of cashflow, and this only under the aegis of central accounting. An option is allowed for the station manager to grant, to a qualified SSC, a larger amount of maximum float, for a minimal period of time.
In the cash transactions described above, two purses, the cash depositor and the cash receiver were simultaneously inserted in a dumb terminal, which monitored the purse to purse negotiations and transaction. Negotiations and transfers were secured internally in the two purse""s smart card. When the money is deposited in the bank, the treasurer may or may not be present at the teller""s counter, and as the system operator will probably not agree that the treasurer""s CCR purse is replenished daily to the same maximum amount, because of normal daily and seasonal fluctuations. The anticipated receipts vary greatly, and there may be a change of treasurers or treasurer""s working venue. A preferred solution to this problem is that the treasurer will receive a blind cheque, that goes through a normal clearance mechanism, wherein the treasurer alone is able to use the cheque to increment his CCR, and he and only he can use the cheque once and only once. An analogy might bexe2x80x94a rogue treasurer receiving a conventional bank check payable to him alone which he wished to use to credit his account several times (in the absence of a clearance mechanism that might detect such a scam); as the check was made from an easily detectable unobtainable paper, and the printing on the checks was impossible to duplicate, no matter what methods he would use, he would be unable to make acceptable copies of the cheque to enable him to credit his account several more times.
A similar situation arises in the United States where the Department of Agriculture issues food credits to the needy. A blind cheque must be issued to each of the indigents, who can only use a cheque once, and the USDA must know who the recipient of the cheque is, and that his purse will only be credited with the given amount a single time, when presented to a potentially fraudulent terminal.
In the present embodiment of the present invention, all payments to station managers, station treasurers, and cash flow managers are made with cheques (CCCRs).
The method used here for assuring that a cheque can be credited, once, and only once, is for the issuer of the cheque to know a unique number, which was provably generated by the receiver""s smart card (SAM) to be used once and only once, which, as the receiver""s protocol is frozen, entitles the receiver to receive a cheque with his primary account number and the unique number only once. This number can be the result of a simple count. In this system, the writer of the cheque knows these numbers, as his smart card (SAM), received the number in an electronically signed request for the cheque for credit for cash receivables (RCCCR), signed duly by the potential recipient of the cheque.
The Bank""s Receiptsxe2x80x94A similar situation arises when the treasurer (or a lottery kiosk collector or a fuel station treasurer) deposits value in the bank. The bank is typically not an active participant in the payment system, but may be willing that the teller be willing to confirm with an electronic receipt (the equivalent of signing a deposit slip), which the teller can sign. This is making no more demand of the teller for actions, other than those he normally executes.
The central accountant""s SAM, and his alone, is programmed to be able to convert a RECeipt from the bank into CCRs. The central accountant""s SAM CCR account is totaled once a day, and converted into a single cheque for the manager of cashflow.
The manager of cashflow sets the strategy for distributing CCCRs to the depot treasurers, and the central accountant reconciles this policy, and prepares unsigned electronic cheques for the manager of cashflow to approve and sign. These cheques are automatically distributed by modem to the depots"" electronic mailboxes for the treasurers to collect and reinstate their CCRs, entitling them to continue collecting $CASH from drivers and cashiers, to be deposited in the bank, to credit the transportation system""s account.
Preferably, parking meters and vending machines, in sensitive to vandalism locations which cannot accept $CASH will be programmed to allow a user to draw a small amount (such as $25) from his credit purse (account) in order to restore his stored value purse and use the meter/machine. In such a case, the meter/machine would be limited with xe2x80x9ccredit for cash receivablesxe2x80x9d, determined by the system operators.
Restraint and constraint strategies to be placed on vendor""s use of xe2x80x9ccash receivedxe2x80x9d in lieu of xe2x80x9ccredit for cash receivablesxe2x80x9d.
Time Restraint
A vendor""s terminal can be programmed so that it must deposit cash received within a certain time bound. In a public transportation scenario, 48 hours is a suitable limit, without levying a fine.
This, obviously, would be unsatisfactory in a situation where very small amounts are involved, as participating merchants, in such a situation would be daunted by the difficulties of handling transactions.
Limiting the Credit for Cash Receivable that a Vendor is Allowed:
In all Fortress vendor and consumer SAMs and smart cards, a value of use limit is put on all purses. The system operator is probably not willing that the vendor collects and holds large amounts of money for long lengths of time which he used to reload customer purses; certainly not without receiving interest for non-payment on time.
This is the xe2x80x9choldxe2x80x9d that the system operator has on the vendor. If a vendor does not comply with the operator""s rules, and has used up his credit for cash receivables, then the vendor may refuse to reissue his credit, and the vendor will then be unable to reload stored value into consumers"" purses.
Coupling the Motivating Bonus which the Vendor receives for handling the cash with interest charged to the vendor for delayed transfer of funds, in those cases where the vendor does not xe2x80x98buyxe2x80x99 the original CCR sum, but is allotted by the system operator.
All cash which is collected by vendors is archived in the vendors"" terminals, dated and certified. All funds collected by a vendor grant him a percentage bonus for handling and transferring the money for clearance, and for his part in collecting payments in advance.
What would be a typical strategy, would consist of a bonus percentage, and an xe2x80x9caverage per day delayed transfer percentagexe2x80x9d.
To demonstrate, let us assume a 3% bonus, a three day grace period, and a {fraction (1/10)}% per day xe2x80x9caverage per day delayed transfer percentagexe2x80x9d, and that a convenience store accepted cash, as appeared in the table from the 10th of the month (the last time cash was transferred) until the 18th of the month, when the convenience store made a bank transfer to the system operator.
Availability of the System:
The above-described cashflow system may be generated as follows: The hardware is supplied off the shelf by Fortress UandT Ltd.
Each work station in a preferred embodiment is an IBM type PC equipped with Windows 3.1 or 95, 16 Mbyte of RAM, a hard disk and a BestCrypt-4-PC drop in card, at least one smart card reader.
An issuer""s workstation is maintained in a very well protected area, used for initializing smart cards and workstation SAMS, and it is used to configure the workstations, each with proper access and priority.
The Smart Cards and SAMS used in the system are the first generation SGS-Thomson ST-CF54 with the first version SCOS+ operating system.